The DBMS must restrict the ability of users to launch Denial of Service (DoS) attacks against other information systems or networks.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-52217	O112-C3-019200	SV-66433r2_rule		Low

Description
When it comes to DoS attacks, most of the attention is paid to ensuring that systems and applications are not victims of these attacks. While it is true that those accountable for systems want to ensure they are not affected by a DoS attack, they also need to ensure their systems and applications are not used to launch such an attack against others. To that extent, a variety of technologies exist to limit, or in some cases, eliminate the effects of DoS attacks. For example, boundary protection devices can filter certain types of packets to protect devices from being directly affected by DoS attacks. Limiting system resources that are allocated to any user to a bare minimum may also reduce the ability of users to launch some DoS attacks. Applications and application developers must take the steps needed to ensure users cannot use these applications to launch DoS attacks against other systems and networks. An example would be designing applications to include mechanisms that throttle network traffic so users are not able to generate unlimited network traffic via the application. The methods employed to counter this risk will be dependent upon the potential application layer methods that can be used to exploit it.

Description

When it comes to DoS attacks, most of the attention is paid to ensuring that systems and applications are not victims of these attacks. While it is true that those accountable for systems want to ensure they are not affected by a DoS attack, they also need to ensure their systems and applications are not used to launch such an attack against others. To that extent, a variety of technologies exist to limit, or in some cases, eliminate the effects of DoS attacks. For example, boundary protection devices can filter certain types of packets to protect devices from being directly affected by DoS attacks. Limiting system resources that are allocated to any user to a bare minimum may also reduce the ability of users to launch some DoS attacks. Applications and application developers must take the steps needed to ensure users cannot use these applications to launch DoS attacks against other systems and networks. An example would be designing applications to include mechanisms that throttle network traffic so users are not able to generate unlimited network traffic via the application. The methods employed to counter this risk will be dependent upon the potential application layer methods that can be used to exploit it.

STIG	Date
Oracle Database 11.2g Security Technical Implementation Guide	2015-03-26

Details

Check Text ( C-54273r2_chk )
Review DBMS settings and custom database code to determine whether the DBMS or database application code could be used to launch DoS attacks. If the DBMS or custom database code would facilitate DoS-style attacks against other information systems, this is a finding. - - - - - The Listener is the key for a denial of service attack. The idea is to flood the database with connection requests so no more connections can be served and ultimately bring down the listener. Check to see how many of these steps to secure the Oracle Listener are in place at your site. (Please refer to the Fix for more detail on implementing these protections.) 1. DISABLING THE DEFAULT LISTENER 2. TURN ON LISTENER LOGGING 3. SET ADMIN_RESTRICTIONS IN THE LISTENER.ORA 4. SET LOCAL_OS_AUTHENTICATION IN THE LISTENER.ORA 5. SET PROTECTION AGAINS CRAFTED NETWORK PACKETS ON DATABASE LEVEL IN 11G. 6. APPLY LISTENER SECURITY PATCHES 7. BLOCK SQL*NET ON FIREWALLS 8. SECURE THE $TNS_ADMIN DIRECTORY 9. SECURE TNSLSNR AND LSNRCTL EXECUTABLES 10. REMOVE UNUSED SERVICES 11. SETUP VALID NODE CHECKING 12. MONITOR THE LOGFILE 13. SET CONNECTION RATE

Check Text ( C-54273r2_chk )

Review DBMS settings and custom database code to determine whether the DBMS or database application code could be used to launch DoS attacks. If the DBMS or custom database code would facilitate DoS-style attacks against other information systems, this is a finding.

- - - - -
The Listener is the key for a denial of service attack. The idea is to flood the database with connection requests so no more connections can be served and ultimately bring down the listener.

Check to see how many of these steps to secure the Oracle Listener are in place at your site. (Please refer to the Fix for more detail on implementing these protections.)

1. DISABLING THE DEFAULT LISTENER
2. TURN ON LISTENER LOGGING
3. SET ADMIN_RESTRICTIONS IN THE LISTENER.ORA
4. SET LOCAL_OS_AUTHENTICATION IN THE LISTENER.ORA
5. SET PROTECTION AGAINS CRAFTED NETWORK PACKETS ON DATABASE LEVEL IN 11G.
6. APPLY LISTENER SECURITY PATCHES
7. BLOCK SQL*NET ON FIREWALLS
8. SECURE THE $TNS_ADMIN DIRECTORY
9. SECURE TNSLSNR AND LSNRCTL EXECUTABLES
10. REMOVE UNUSED SERVICES
11. SETUP VALID NODE CHECKING
12. MONITOR THE LOGFILE
13. SET CONNECTION RATE

Fix Text (F-57033r4_fix)
Configure DBMS settings to restrict functionality that could be used to initiate DoS attacks. Modify custom database code to prevent its being used to initiate DoS attacks. Secure the Oracle Listener in the following steps: 1. DISABLING THE DEFAULT LISTENER 2. TURN ON LISTENER LOGGING 3. SET ADMIN_RESTRICTIONS IN THE LISTENER.ORA 4. SET LOCAL_OS_AUTHENTICATION IN THE LISTENER.ORA 5. SET PROTECTION AGAINST CRAFTED NETWORK PACKETS ON DATABASE LEVEL IN 11G. 6. APPLY LISTENER SECURITY PATCHES 7. BLOCK SQLNET ON FIREWALLS 8. SECURE THE $TNS_ADMIN DIRECTORY 9. SECURE TNSLSNR AND LSNRCTL EXECUTABLES 10. REMOVE UNUSED SERVICES 11. SETUP VALID NODE CHECKING 12. MONITOR THE LOGFILE 13. SET CONNECTION RATE Step 1 - Disable the Default Listener All listeners have a name instead of the name LISTENER and have a startup protection. LISTENER=(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST=)(PORT = 0))) This configuration prevents the default listener from starting. The error serves as a reminder to set TNS_ADMIN, if necessary, and to supply the correct listener name to the lsnrctl command. $ lsnrctl start ... Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=)(PORT=0))) TNS-01103: Protocol specific component of the address is incorrectly specified TNS-12533: TNS:illegal ADDRESS parameters TNS-12560: TNS:protocol adapter error TNS-00503: Illegal ADDRESS parameters Step 2 - Turn on Logging Turn on logging for all listeners in order to capture Listener commands and brute force password attacks. LSNRCTL> set current_listener LSNRCTL> set password : LSNRCTL> set log_directory /network/admin LSNRCTL> set log_file .log LSNRCTL> set log_status on LSNRCTL> save_config Step 3 - Set ADMIN_RESTRICTIONS in the listener.ora With ADMIN_RESTRICTIONS_listener=on, the listener rejects SET commands that might have been sent from an intruder on a remote system. It only allows changes through lsnrctl reload on the local system LISTENER.ORA. ADMIN_RESTRICTIONS_ = ON Step 4 - Set LOCAL_OS_AUTHENTICATION in the listener.ora By default, the Listener cannot be remotely managed and can only be managed locally by the owner of the tnslsnr process (usually oracle) since Oracle 10G. LOCAL_OS_AUTHENTICATION_ = ON Step 5 - Set Protection against crafted network packets on database level in 11g SEC_PROTOCOL_ERROR_TRACE_ACTION: SEC_PROTOCOL_ERROR_TRACE_ACTION specifies the action that the database should take when bad packets are received from a possibly malicious client. SEC_PROTOCOL_ERROR_TRACE_ACTION = { NONE \| TRACE \| LOG \| ALERT } NONE: The database server ignores the bad packets and does not generate any trace files or log messages. TRACE: A detailed trace file is generated when bad packets are received, which can be used to debug any problems in client/server communication. LOG: A minimal log message is printed in the alert logfile and in the server trace file. A minimal amount of disk space is used. ALERT: An alert message is sent to a DBA or monitoring console. SEC_PROTOCOL_ERROR_FURTHER_ACTION SEC_PROTOCOL_ERROR_FURTHER_ACTION specifies the further execution of a server process when receiving bad packets from a possibly malicious client. SEC_PROTOCOL_ERROR_FURTHER_ACTION = { CONTINUE \| (DELAY,integer) \| (DROP,integer) } CONTINUE: The server process continues execution. The database server may be subject to a Denial of Service (DoS) if bad packets continue to be sent by a malicious client. (DELAY,integer):The client experiences a delay of integer seconds before the server process accepts the next request from the same client connection. Malicious clients are prevented from excessive consumption of server resources while legitimate clients experience degradation in performance but can continue to function. (DROP,integer): The server forcefully terminates the client connection after integer bad packets. The server protects itself at the expense of the client (for example, a client transaction may be lost). The client may reconnect and attempt the same operation. SEC_MAX_FAILED_LOGIN_ATTEMPTS SEC_MAX_FAILED_LOGIN_ATTEMPTS specifies the number of authentication attempts that can be made by a client on a connection to the server process. After the specified number of failure attempts, the connection will be automatically dropped by the server process. SEC_MAX_FAILED_LOGIN_ATTEMPTS = n (10 is the default) Values ranges 1 to unlimited Step 6 - Apply Listener Security Patches Critical Patch Updates are cumulative, therefore, the latest patch will contain all previous security patches for the Listener. Step 7 - Block SQLNet on Firewalls Firewall filters should be designed to only allow SQLNet traffic from known application and web servers. SQLNet traffic from application servers in the DMZ should be permitted only to access specific database servers. Step 8 - Secure the $TNS_ADMIN Directory Place the listener.ora, sqlnet.ora, and protocol.ora files in the $TNS_ADMIN directory. It should be read/write/execute for only the primary oracle account and no permissions for any other account (for UNIX and Linux 0600). The tnsnames.ora file permissions should be set to 0644 on UNIX and Linux. Step 9 - Secure TNSLSNR and LSNRCTL executables The executables tnslsnr and lsnrctl in the $ORACLE_HOME/bin should be protected. Set the file permissions to 0751 on UNIX and Linux as recommended by Oracle. It is possible to change the file permissions to 0700 which would be more secure, although this should be thoroughly tested in your environment. Step 10 - Remove Unused Services Default installations have a listener entry for PL/SQL External Procedures (ExtProc or PLSExtProc) and databases with default services. Remove the Unused services from database or listener. The database initialization parameter LOCAL_LISTENER must be set so that the database is able to dynamically register with the Listener. See Metalink Note ID 359277.1 Step 11 - Setup Valid Node Checking Valid node checking is an interesting security feature that protects DBMS instances from malevolent or errant Oracle Net connections over TCP/IP, without the need for a firewall or IP address filtering at the operating system-level. The feature is controlled by the three parameters tcp.validnode_checking, tcp.invited_nodes, and tcp.excluded_nodes. Valid node checking could be enabled dynamically in Oracle10g and Oracle11g. This works only if the configuration file sqlnet.ora was present when the TNS Listener was started. There's no sense in setting both tcp.invited_nodes and tcp.excluded_nodes at the same time, since even nodes not mentioned explicitly as excluded nodes will still be excluded when tcp.invited_nodes is set. tcp.validnode_checking Turns valid node checking on or off. tcp.invited_nodes List of nodes that may connect to the TNS Listener. A comma separated list of host names and/or IP addresses on a single line. tcp.excluded_nodes List of nodes that are denied a connection to the TNS Listener. A comma-separated list of host names and/or IP addresses on a single line. Step 12 - Monitor the logfile The logfile may contain TNS-01169, TNS-01189, TNS-01190, or TNS-12508 errors, which may signify attacks or inappropriate activity, monitor the logfile and generate an alert whenever these errors are encountered. Step 13 - Set Connect Rate CONNECTION_RATE_LISTENER=10 LISTENER= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=yes)) (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=yes)) (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1526)) ) LISTENER= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=8)) (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=12)) (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1526)) ) For more information see: Oracle Support Note ID 92602.1 "How to Password Protect the Listener" Oracle Support Note ID 124742.1 "Vulnerability in the Oracle Listener Program" Oracle Support Note ID 260986.1 "Setting Listener Passwords With an Oracle 10g Listener" Oracle Support Note ID 359277.1 "Changing Default Listener Port Number" Oracle Support Note ID 332785.1 "How To Disable Local OS Authentication For Lsnrctl Utility"

Fix Text (F-57033r4_fix)

Configure DBMS settings to restrict functionality that could be used to initiate DoS attacks.

Modify custom database code to prevent its being used to initiate DoS attacks.

Secure the Oracle Listener in the following steps:

1. DISABLING THE DEFAULT LISTENER
2. TURN ON LISTENER LOGGING
3. SET ADMIN_RESTRICTIONS IN THE LISTENER.ORA
4. SET LOCAL_OS_AUTHENTICATION IN THE LISTENER.ORA
5. SET PROTECTION AGAINST CRAFTED NETWORK PACKETS ON DATABASE LEVEL IN 11G.
6. APPLY LISTENER SECURITY PATCHES
7. BLOCK SQL*NET ON FIREWALLS
8. SECURE THE $TNS_ADMIN DIRECTORY
9. SECURE TNSLSNR AND LSNRCTL EXECUTABLES
10. REMOVE UNUSED SERVICES
11. SETUP VALID NODE CHECKING
12. MONITOR THE LOGFILE
13. SET CONNECTION RATE

Step 1 - Disable the Default Listener
All listeners have a name instead of the name LISTENER and have a startup protection.
LISTENER=(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST=)(PORT = 0)))

This configuration prevents the default listener from starting. The error serves as a reminder to set TNS_ADMIN, if necessary, and to supply the correct listener name to the lsnrctl command.
$ lsnrctl start
...
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=)(PORT=0)))
TNS-01103: Protocol specific component of the address is incorrectly specified
TNS-12533: TNS:illegal ADDRESS parameters
TNS-12560: TNS:protocol adapter error
TNS-00503: Illegal ADDRESS parameters

Step 2 - Turn on Logging
Turn on logging for all listeners in order to capture Listener commands and brute force password attacks.
LSNRCTL> set current_listener
LSNRCTL> set password :
LSNRCTL> set log_directory /network/admin
LSNRCTL> set log_file .log
LSNRCTL> set log_status on
LSNRCTL> save_config

Step 3 - Set ADMIN_RESTRICTIONS in the listener.ora
With ADMIN_RESTRICTIONS_listener=on, the listener rejects SET commands that might have been sent from an intruder on a remote system. It only allows changes through lsnrctl reload on the local system LISTENER.ORA.
ADMIN_RESTRICTIONS_ = ON

Step 4 - Set LOCAL_OS_AUTHENTICATION in the listener.ora
By default, the Listener cannot be remotely managed and can only be managed locally by the owner of the tnslsnr process (usually oracle) since Oracle 10G.
LOCAL_OS_AUTHENTICATION_ = ON

Step 5 - Set Protection against crafted network packets on database level in 11g

SEC_PROTOCOL_ERROR_TRACE_ACTION:
SEC_PROTOCOL_ERROR_TRACE_ACTION specifies the action that the database should take when bad packets are received from a possibly malicious client.
SEC_PROTOCOL_ERROR_TRACE_ACTION = { NONE | TRACE | LOG | ALERT }

NONE: The database server ignores the bad packets and does not generate any trace files or log messages.

TRACE: A detailed trace file is generated when bad packets are received, which can be used to debug any problems in client/server communication.

LOG: A minimal log message is printed in the alert logfile and in the server trace file. A minimal amount of disk space is used.

ALERT: An alert message is sent to a DBA or monitoring console.

SEC_PROTOCOL_ERROR_FURTHER_ACTION
SEC_PROTOCOL_ERROR_FURTHER_ACTION specifies the further execution of a server process when receiving bad packets from a possibly malicious client.
SEC_PROTOCOL_ERROR_FURTHER_ACTION = { CONTINUE | (DELAY,integer) | (DROP,integer) }

CONTINUE: The server process continues execution. The database server may be subject to a Denial of Service (DoS) if bad packets continue to be sent by a malicious client.

(DELAY,integer):The client experiences a delay of integer seconds before the server process accepts the next request from the same client connection. Malicious clients are prevented from excessive consumption of server resources while legitimate clients experience degradation in performance but can continue to function.

(DROP,integer): The server forcefully terminates the client connection after integer bad packets. The server protects itself at the expense of the client (for example, a client transaction may be lost). The client may reconnect and attempt the same operation.

SEC_MAX_FAILED_LOGIN_ATTEMPTS
SEC_MAX_FAILED_LOGIN_ATTEMPTS
specifies the number of authentication attempts that can be made by a client on a connection to the server process. After the specified number of failure attempts, the connection will be automatically dropped by the server process.

SEC_MAX_FAILED_LOGIN_ATTEMPTS = n (10 is the default)

Values ranges 1 to unlimited

Step 6 - Apply Listener Security Patches
Critical Patch Updates are cumulative, therefore, the latest patch will contain all previous security patches for the Listener.

Step 7 - Block SQL*Net on Firewalls
Firewall filters should be designed to only allow SQL*Net traffic from known application and web servers. SQL*Net traffic from application servers in the DMZ should be permitted only to access specific database servers.

Step 8 - Secure the $TNS_ADMIN Directory
Place the listener.ora, sqlnet.ora, and protocol.ora files in the $TNS_ADMIN directory.

It should be read/write/execute for only the primary oracle account and no permissions for any other account (for UNIX and Linux 0600). The tnsnames.ora file permissions should be set to 0644 on UNIX and Linux.

Step 9 - Secure TNSLSNR and LSNRCTL executables
The executables tnslsnr and lsnrctl in the $ORACLE_HOME/bin should be protected. Set the file permissions to 0751 on UNIX and Linux as recommended by Oracle. It is possible to change the file permissions to 0700 which would be more secure, although this should be thoroughly tested in your environment.

Step 10 - Remove Unused Services
Default installations have a listener entry for PL/SQL External Procedures (ExtProc or PLSExtProc) and databases with default services. Remove the Unused services from database or listener.
The database initialization parameter LOCAL_LISTENER must be set so that the database is able to dynamically register with the Listener. See Metalink Note ID 359277.1

Step 11 - Setup Valid Node Checking
Valid node checking is an interesting security feature that protects DBMS instances from malevolent or errant Oracle Net connections over TCP/IP, without the need for a firewall or IP address filtering at the operating system-level. The feature is controlled by the three parameters tcp.validnode_checking, tcp.invited_nodes, and tcp.excluded_nodes. Valid node checking could be enabled dynamically in Oracle10g and Oracle11g. This works only if the configuration file sqlnet.ora was present when the TNS Listener was started. There's no sense in setting both tcp.invited_nodes and tcp.excluded_nodes at the same time, since even nodes not mentioned explicitly as excluded nodes will still be excluded when tcp.invited_nodes is set.

tcp.validnode_checking
Turns valid node checking on or off.

tcp.invited_nodes
List of nodes that may connect to the TNS Listener. A comma separated list of host names and/or IP addresses on a single line.

tcp.excluded_nodes
List of nodes that are denied a connection to the TNS Listener. A comma-separated list of host names and/or IP addresses on a single line.

Step 12 - Monitor the logfile
The logfile may contain TNS-01169, TNS-01189, TNS-01190, or TNS-12508 errors, which may signify attacks or inappropriate activity, monitor the logfile and generate an alert whenever these errors are encountered.

Step 13 - Set Connect Rate
CONNECTION_RATE_LISTENER=10

LISTENER=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=yes))
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=yes))
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1526))
)
LISTENER=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=8))
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=12))
(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1526))
)
For more information see:
Oracle Support Note ID 92602.1 "How to Password Protect the Listener"
Oracle Support Note ID 124742.1 "Vulnerability in the Oracle Listener Program"
Oracle Support Note ID 260986.1 "Setting Listener Passwords With an Oracle 10g Listener"
Oracle Support Note ID 359277.1 "Changing Default Listener Port Number"
Oracle Support Note ID 332785.1 "How To Disable Local OS Authentication For Lsnrctl Utility"